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PREFACE 



This manual describes Digital Equipment Corporation's remote diagnosis facility, the KLIO 
/ntegrated A'^etwork for /nvestigation and A^orrection, hereafter referred to as KLINIK, 

The manual provides a conceptual and technical description of how KLINIK is to be used by field 
service as an integral part of the branch-resource-based maintenance philosophy for KLlO-based 
systems. 

Reference to other documents is necessary to fully understand the nature and application of the 
maintenance software tools utilized via a KLINIK link. 



SECTION 1 
SIMPLIFIED KLINIK DESCRIPTION 



1.1 SIMPLIFIED KLINIK DESCRIPTION 

The KLINIK remote diagnosis system is based on a computer system whose traditional console con- 
trol/mvestigation functions can be manipulated over a telephone line. This remote control capability is 
available to anyone who can properly interface to a telephone line and who has the knowledge and 
credentials needed pass through the computer's security system. 

The effectiveness of KLINIK depends on the ability of the user and the features/capabilities designed 
into the computer system's hardware and software. 

1.2 UTILIZATION ON KLIO-BASED SYSTEMS 

All KLlO-based systems will have the KLINIK remote diagnosis capability while running standalone 
diagnostics, TOPSIO or TOPS20 (RSX20F). This capability is provided by a second DLl 1 (DLllE) in 
the PDP-1 1/40 Front End Processor. This DLl IE will be connected to a modem (Bell 103A3) that will 
be provided by the customer at each contract site. 

A remote TTY (with acoustic coupler) could use this DLl IE to log onto the system. This privilege has 
to be given by the site operator for security reasons. Both diagnostic and monitor software are pre- 
pared to handle this remote TTY. In most modes, the second TTY appears, when connected, as a 
second CTY with all the privileges associated with that device. Essentially, this means that the normal 
CTY will operate in parallel with the remote TTY. Any commands entered on either TTY will be 
accepted and the CPU will echo to both TTYs simultaneously. Consequently, everything that is input 
or output to one will appear on the other. 

1.3 USE OF THE REMOTE DIAGNOSIS FEATURE 

There are four main ways in which the KLINIK remote diagnosis feature will be utilized. These are: 

1. Performance monitoring, statistics gathering, and some preventive maintenance. 

2. Initial troubleshooting of a problem by an engineer in the branch. 

3. Support-level assistance by a regional or Maynard support engineer. 

4. Remote reconfiguration assistance. 

1.3.1 Performance Monitoring and Preventive Maintenance 

The work in these categories is very similar to that which can now be performed with a remote termi- 
nal. However, because the KLINIK feature is a maintenance requirement, DIGITAL is guaranteed 
access at any time (if the customer permits), regardless of how busy the user's communication equip- 
ment is. 
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Essentially, the procedure is for an engineer in the local branch to log onto a system and examine the 
SYSERR file. If this shows failures that require further investigation, he then runs any of the normal 
timeshared diagnostics. (If the SYSERR file shows no problems, the branch engineer may still want to 
run some diagnostics.) After analyzing the results of these diagnostics, the engineer decides on an 
appropriate course of action to correct the problem. He can then schedule corrective maintenance time 
with the customer, select the appropriate set of spares and test equipment from the stockroom, and be 
prepared to make a short, productive trip to the site. 

1.3.2 Initial Troubleshooting 

Field service's goal for the KLIO project is a 1:3 man:machine ratio. Therefore, it is likely that a field 
service engineer will not be on-site when a failure occurs. 

When a failure occurs, the customer will call his field service representative in the local branch. This 
engineer will then log in (even if the KLIO is down) and run diagnostics. When he has isolated the error 
as closely as possible, he can select the appropriate spares, test equipment, etc., before leaving for the 
site. 

In fact, if there is more than one engineer in the branch, the engineer with the most experience on the 
option which has failed can take the call. 

1.3.3 Support Assistance 

A support engineer takes the following attributes with him on the call: 

1. A fresh approach to the problem. 

2. A higher level of expertise on the failing device. 

The use of the remote TTY link allows both these capabilities to be brought to bear on a problems with 
no delays due to travel time, previous commitments, etc. 

Because the lights and switches on the KLIO are simulated by the PDP-11 Front End Procesor, any 
support engineer on a remote TTY will have the same information that is available on-site. The only 
limitations for the remote support engineer are that he cannot do basic booting or operate the 
oscilloscope. Even these restrictions are not as important as in the past. The implementation of special 
diagnostic features, such as the ability of the PDP- 1 1 Front End Processor to read most major registers 
and signals, together with the machine architecture - microprogrammed (and therefore clocked) with 
another computer monitoring its operation - inevitably mean less dependence on signal tracing with 
an oscilloscope. 

Most faults not identified by the diagnostic module callout can be found through a full understanding 
of the machine operation and the various features available in the diagnostic "console" package. The 
use of an oscilloscope should only be necessary if the failure is on a bus between modules, if it is a close 
timing problem, or if it is in the peripheral equipment. 

1.3.4 Reconfiguration Assistance 

In many cases, malfunctions occur which are such that the system can be reconfigured and continue to 
operate in a degraded mode. Repair can then be scheduled at a more convenient time. Although it is 
planned to allow the customer to take the necessary steps to reconfigure and continue timesharing 
operation by providing him with directional information, there will be times when the field service 
engineer, via KLINIK, will assist in this prbcess. 
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1.4 SECURITY ASPECTS OF THE KLINIK REMOTE DIAGNOSIS NETWORK 

Computer system security is presently the subject of a great deal of effort and money. In 1972, IBM 
initiated a long-range program designed to improve data security knowledge and technology. As part 
of that program, it funded specific investigations at four major sites. These included MIT (DECsystem 
10) and TRW Systems, Inc. (DIGITAL customers). 

DIGITAL believes that IBM's findings at TRW Systems concerning the IBM RETAIN/370 remote 
diagnosis system summarize the security problem found by most DIGITAL customers: 

In considering emergency maintenance or preventative maintenance pro- 
cedure, the following question must be addressed: "Are there certain pro- 
grams or data files from which the CE or programming systems 
representative must be restricted?" When the CE uses dedicated hardware or 
software tools, operations personnel can simply unload and remove all sensi- 
tive data. In the case of concurrent maintenance and systems operation, this 
may not be possible. From a system availability viewpoint, this concurrent 
maintenance is highly desirable; however, it leaves a potentially huge vulner- 
ability to consider. Under these circumstances, a maintenance procedure 
must be estabHshed for dealing with the computer system's failure and sensi- 
tive on-line programs/data. When considering this question, the use of such 
tools as IBM's RETAIN/ 370 must also be considered because in this case and 
in conjunction with the local CE, remote specialists may have access (maybe 
total access) to the central facility.' 

This quotation describes precisely the problem with KLINIK. The solution to the problem is relatively 
siraightforward and consists of ensuring that: 

1. It is a DIGITAL employee who is calling. 

2. The DIGITAL employee has a legitimate reason for assuming full console control. 

3. Overt operator action is required to allow the special communications line to assume full 
console control (i.e., a special password has to be input to the PDP-11 by the operator). 

and furthermore, if the customer wishes, 

4. Overt operator action is required to enable the special communications Hne (i.e., the oper- 
ator has to manually answer the data set phone rather than having it in auto-answer). 

There are four possible situations in which DIGITAL would want to log onto the customer's system. 
These situations and the procedures for handling them are: 

1 . Customer the placed call; DIGITAL to log in as normal timesharing job. 

This is a very safe arrangement; the customer should be sure to call only the normal DIGI- 
TAL office phone numbers. (DIGITAL will supply each site with a list of phone numbers 
for the KLINIK centers.) 

2. Customer placed the call; DIGITAL to assume full console control. 

This is reasonably safe; again, we emphasize that the customer should only call the normal 
DIGITAL office phone numbers. When he talks to the DIGITAL representative, he will tell 
him the special password to use (in user mode) to allow him to assume full console control, 
or will boot and enable the exec-standalone diagnostic control package (KLDCP). 



'IBM Corporation, Data Security and Data Processing, Volume 5, p. 58, 1974. 
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3. DIGITAL placed the call; DIGITAL to log in as normal timesharing job. 

This situation is secure because the caller still has to log in with the normal PPN/password 
dialogue to monitor and is not getting any special privileges. Furthermore, the remote line 
will be inhibited from logging in if the customer has "NOT REMOTE LOGIN" status set 
(e.g., if he did not want any remote user while a payroll was being run). 

4. DIGITAL placed the call; DIGITAL to assume full console control. 

This is by far the most insecure and suspect case. A legitimate question that the customer 
should ask is "Why does DIGITAL want full console control when I haven't asked for 
help?" It would seem that there is no valid reason for DIGITAL to take this privilege on its 
own initiative. Consequently, in order to obtain maximum security, the following steps 
should be taken. 

a. A DIGITAL representative should phone the customer and explain why he needs full 
console control. 

b. The customer, when DIGITAL has explained its request, should terminate that phone 
conversation without giving the special password (which would be required in addition 
to the normal PPN/password dialogue). He should then call DIGITAL back and give 
the special password. This ensures that the customer calls a DIGITAL office number 
and that he does not get misled by a call purporting to be from a DIGITAL employee. 

1.4.1 Conclusion 

In general, we must ensure that the customer is talking to DIGITAL, especially when full console 
control is to be given. To achieve this, the customer must only call official DIGITAL office numbers. 

If at any time the customer is requested to use a non-standard DIGITAL number (e.g., a software 
specialist using a portable terminal in a local motel room), then he should verify the number by calling 
a DIGITAL representative at a normal number or he should personally know the location of the 
phone (i.e., the software specialist has been on-site and personally given the customer his temporary 
number). 

1.4.2 Future Considerations 

In the future, DIGITAL may wish to have the ability to call all sites automatically by an auto-call unit 
on a system in Marlboro, Massachusetts. This would allow automatic collection of performance 
statistics. 
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SECTION 2 
TECHNICAL DESCRIPTION 



The following descriptions are intended to provide a fundamental understanding of KLINIK - KLIO 
/ntegrated TVetwork for /nvestigation and ATorrection - and how it works. 

2.1 HARDWARE/SOFTWARE/USER FUNCTIONAL ORGANIZATION 

Figure 2-1 illustrates the KLINIK hardware/software/user functional organization that exists in all 
KLlO-based systems employing the KLINIK facility. 

The left-hand side of the figure depicts a KLlO-based system and the hardware and software systems 
which reside on-site and establish the KLINIK hnk. 

The right-hand side of the figure depicts the user community in order of potential usage, beginning at 
the top with the branch field service offices. Any one of these users may employ the KLINIK facility. 

2.2 SITE HARDWARE CHARACTERISTICS 

Figure 2-2 illustrates the KLINIK DLllE to Bell 103A3 interconnection, which is required during the 
installation of the KLINIK facility on a KLlO-based system. 

The left-hand side of the figure illustrates the PDP-11/40 to DLllE to BC05C connection and the 
right-hand side illustrates the Bell system to Bell 103A3 to BC05C connection. 

The signal and pin connections are for reference. 

All indicated requirements for DLllE and Bell 103A3 must be met before communication can be 
established via KLINIK. 

2.3 KLINIK USER EQUIPMENT 

Figure 2-3 illustrates the KLINIK user equipment which is typically required to establish single-user 
communication with the KLINIK faciHty. 

Any 300 baud asynchronous terminal interface to the Bell phone system will work. The diacram 
portrays the simplest method. 

2.4 BRANCH KLINIK CENTER FUNCTIONS 

Figure 2-4 illustrates the branch KLINIK center functions that must be employed to achieve efficiency 
in overall maintenance of the KLlO-based systems. 

It basically depicts a KLlO-based system communicating via the KLINIK link to the branch field 
ottice. Inside the office are listed the functions which take place in the branch, based on data obtained 
from the KLIO system via the KLINIK link. 
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Figure 2-1 KLINIK Hardware/Software/User Functional Organization 
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Figure 2-2 KLINIK DLl IE to Bell 103A3 Interconnection 
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Figure 2-3 KLINIK User Equipment 
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The ultimate outcome of a malfunction is depicted by indicating the repair resources being dispatched 
from the branch to the KLlO-based system as the end result of "action." 

The following is a breakdown of the KLINIK functions: 

1 . Auto Diagnosis Analysis - The KL 1 operating systems are capable of diagnosing themselves 
through internal error detection and reporting which is analyzed via SYSERR and the abili- 
ty to run user mode diagnostics periodically via batch files and analyzing the results. 

This function is normally invoked by the branch, periodically, as a preventive maintenance 
function. 

2. Call-Invoked Diagnosis - Customer-placed calls usually require the branch to invoke some 
form of diagnostic execution. 

Based on the nature of the apparent malfunction, the field service engineer might run user 
mode diagnostics (including SYSERR) with the system still up, or he might need to run 
executive mode diagnostics if the system is non-operational or if he cannot diagnose in user 
mode. 

3. Diagnosis Result Analysis - The results of any diagnosis must be analyzed to determine of 
what action is best for a given situation. 

In some cases, the malfunction cannot be reproduced and/or was caused by elements out- 
side of a hardware malfunction. In these cases, the repair mode must be determined and the 
possibilities of reconfiguring the system such that it can be operational in a degraded mode 
must be investigated. 

4. Action - All discovered malfunctions require action in some form. The system may be 
reconfigured to bypass a malfunctioning component in some cases and repair is scheduled 
immediately in user mode or deferred until later (probably in exec mode). 

Eventually the malfunction repair is initiated. Based on the diagnosis analysis, the most 
qualified available manpower is selected, the needed parts and test equipment are deter- 
mined, and the repair call is initiated. 

2.5 BRANCH LOGISTICS OPERATION 

Figure 2-5 illustrates the branch logistics operation. 

The branch is initially sent a predetermined set of replacement parts for every option that it must 
service. With the exception of a few site parts (power and PM), the initial kits will remain in the 
branch. 

The figure should be viewed from the center, which depicts the branch office. The KLINIK remote 
diagnosis center on the left is shown connected to three KLIO sites. This facility is also shown diagnos- 
ing and dispatching three typical repair calls: 

1. Diagnosed to RP04 unit - Take kit on call. 

2. Diagnosed KLIO CPU to module - Take module on call. 

3. Diagnosed to PDP-1 1/40 basic malfunction - Take basic PDP-1 1/40 kits on call. 
The bottom portion of the figure depicts the basic logistics flow for bad parts (modules). 
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Figure 2-4 Branch KLINIK Center Functions 



2-6 































SITE A 






SITEB 






SITEC 




MASS 
BUS 

' 2 '■ 


KL10 
CPU 


11/40 
CONSOLE 


MASS 
BUS 


KL10 
CPU 

—'I'" 


11/40 
CONSOLE 


MASS 
BUS 


KL10 
CPU 


11/40 
CONSOLE 












h h 




1 


^ 


KITS 








R 


T 


D 


T 


T 


R 


D 

T 
E 


D 

M 
A 


D 

1 
A 




M 


T 


T 




C 


R 


T 


C 


1 


c 


L 






P 



U 

1 


X 

1 


X 



U 

7 


H 
2 


KL10 
CPU 


A 
2 


M 



U 
4 


11/40 
CPU 




R 


H 
1 


C 

1 



M 


p 

T 


D 

R 


A 
3 






4 


6 





1 













2 


5 




E 


1 


1 


M 






6 








1^1 IMII^ 




. 









REMOTE DIAGNOSIS 








Y 


INVENTORY CTRL 








P 










REPAIR CONTROL 








n 




u 


» UNIT 


INITIAL 

STOCK 

REG. 


BUILD 












• MODULE 








PART 
REQUEST 


GOOD 
PARTS 


BAD 
PARTS 




UP 

STOCK 

REQ. 




















► SUBSYSTEM 


1 
























1 








CYCO 


1 MONTH 
















1 


' 




■ 














STOCK 


FLOAT 


REPAIR 




CONTROL 






ROOM 


STOCK 


CONTROL 




DISTRIBUTION 






17 


SR17 


SRI 26 




SR17 








































10 


224! 



Figure 2-5 Branch Logistics Operation 



2.6 KLINIK - EXEC MODE OPERATIONAL DETAILS 

When the KLIO is in exec or standalone mode, the diagnostic program KLDCP is used to execute the 
diagnostics, establish the diagnostic console, and establish the KLINIK communication link. 

The procedure for establishing the KLINIK link is listed below. This procedure can vary, depending 
on whether the KLIO installation has a regular telephone in the computer room for voice commu- 
nication or only has the Bell 103A3 for voice communication. In either case, the Bell 103A3 must be in 
"AUTO" and ringing when the operator types the KLINIK command. 

1 . Dial the computer operator on a regular phone or the Bell ia3A3. (It must be in "TALK.") 

2. Instruct the operator to bring down the system and remove all volatile media (tapes, disks). 

3. Have the operator mount the KLAD pack on drive and/or any other required diagnostic 
media. 

4. Have the operator boot KLDCP via the manual boot switches (disk boot if using KLAD 
pack; floppy or DECtape boot if not using KLAD pack). 

5. If the Bell 103A3 is utilized for voice communication, it must be hung up by the operator 
and placed in "AUTO." 

6. Dial the KLINIK Bell 103A3 number. When it rings, the remote handset should be placed 
in the DFOl acoustic coupler. The operator must then type "KLINIK" to KLDCP while the 
phone is ringing. 

7. KLDCP will respond with "KLINIK ENABLED" if the Unk has been successfully 
established. 

If "KLINIK ENABLED" is not returned, repeat the operation with an alternate KLDCP 
load device. A failure after this procedure will indicate faulty KLINIK communication 
hardware if the local CTY gets a message, "NO CLEAR TO SEND - KLINIK 
CLEARED." 

No response at either terminal suggests a basic front end processor malfunction; KLDCP 
will not boot. 

8. Commands may now be executed by KLDCP via the KLINIK link. Both the remote KLI- 
NIK terminal and the local CTY are in parallel, echoing whatever is typed by either one. 

9. Messages may be transmitted in either direction by preceding the message with a semicolon 
10. The retyping of "KLINIK" by either TTY will clear the KLINIK link. 
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